The present invention relates generally to deploying applications, and in particular to providing a standardized framework and packaging format for deploying applications to heterogeneous servers.
Presently, many problems are met when deploying features to servers such as web servers, servlet containers, application servers, and Enterprise Services Buses (ESB). One such problem is the inability to provide for deployment into any container or server while making contextual changes. Servers frequently require deployments containing updates, upgrades, patches, functionality enhancements, and so on. Each server may be customized differently from other servers, thereby requiring a customized deployment. Each server may also require a unique deployment to implement specific functions. The dissimilar requirements of each server strains developers since they must focus on supporting multiple servers with customized deployment solutions. Further, developers are forced to develop deployments for many different types of servers which may require specific deployment packages with unique file formats, file structures, languages, and so on. Developers' resources are consumed as they try to develop deployments with these diverse requirements while customers' costs are increased since they must seek additional consulting for their customization issues. Moreover, the developers' efforts in supporting different servers and needs divert their focus from improving the quality of a deployment's contents.
Further, these limitations cause some developers to avoid supporting multiple server types altogether. Instead, these developers hope to concentrate on the features of a deployment directed to only one or a small set of server types. In so doing, developers forfeit support and deployment availability for many other potential server types.
FIG. 1 illustrates a deployment approach of the prior art. In the deployment approach 100, a development environment 101 includes a development platform 102 and archive files 104, 106, and 108. Each of the archive files 104, 106, and 108 include a deployment and are separately developed for each of the servers 110, 112, and 114. In other words, archive file 104 is developed specifically for server 110 and cannot be used for deployment to either server 112 or 114. One problem with this approach is that separately developing deployment files for each and every server is costly and error-prone. Also, disconnected deployments further complicate future support and patches to these servers.
FIG. 2 illustrates another deployment approach of the prior art. In the deployment approach 200, a development environment 201 includes a development platform 202 and a single archive file 206. The archive file 206 includes a deployment and is developed for all of the servers 210, 212, and 214. In other words, archive file 206 is not developed specifically for any one server and can be used for deployment to servers 210, 212, and 214. Servers 210, 212, and 214 may each require at least some differing or mutually exclusive features. For deployment to server 210, the archive file 206 contains unnecessary, unneeded, and/or unwanted features since it contains other features directed only to servers 212 and 214. Similarly, for deployment to server 212, the archive file 206 contains excessive features inappropriate for servers 210 and 214. In addition, the archive file 206 contains features that are improper for server 210, 212, and 214 since it may contain features only for other customers' servers (not shown) as well. Drawbacks with this approach are that the deployment cannot be customized for individual servers, packages are excessively large, and some unneeded or unwanted features may be inadvertently deployed to a server.
FIG. 3 illustrates yet another deployment approach of the prior art. In the deployment approach 300, a development environment 301 includes a development platform 302, a set of archive files 305, templates 316, and a deployment engine 318. Customer deployment model information 320 includes information regarding the deployment to servers 310, 312, and 314. The deployment engine 318 generates archive file 306 based on the set of archive files 305, the templates 316, and customer deployment model information 320. This approach offers an advantage over previous approaches since it allows dynamic development of a customized archive file. This archive file can contain a custom deployment to a single customer with only the features necessary for servers 310, 312, and 314. Unfortunately, one disadvantage with this approach is that the archive file is not separated into independent parts for deployment to different servers, and thus must contain all features for all deployments. For example, the archive file may contain features for server 310 that are improper for server 312.
An application may be deployed in a multiple cluster topology, where more than one node exists. Also, an application may be deployed in a distributed topology, where the application is split and deployed to multiple targets. Clustered and distributed topologies are not mutually exclusive, and in a distributed topology any given target can be a single node or a cluster. For applications deployed in such topologies, current solutions are not capable of dynamically dividing a deployment based on specific features required by servers and generating separate archive files containing only the features necessary for their target servers. In addition, current solutions do not offer the ability to easily perform a distributed deployment where customers have the ability to easily select which features will be deployed to which servers.
Also, current deployment solutions fail to support deployment to heterogeneous servers. A deployment that can be deployed to one type of server must be rewritten for every other type of server to which the deployment may need to be deployed. This impediment is compounded by the limitless configurations each server may have.
Developers and customers are increasingly seeking solutions that are more cost-effective, customizable, maintainable, and robust while applications and their deployments continue to become more complicated. Currently, a deployment needs to be developed specifically for each server and each possible deployment scenario. With infinite possibilities of how customers can choose to deploy, support is only possible via consulting, which increases customers' cost.
Therefore, an improved deployment approach is desirable, including the ability for deploying deployments to heterogeneous servers, servers in multiple cluster and distributed mode topologies, and/or servers in multiple deployment environments. The approach would preferably reduce cost by reducing customizations and be capable of supporting multiple variations in deployment choices easily and consistently. The approach would also make delivery of support easier for additional servers.